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Principles of 00 design: 
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Alan Knight 


or, everything I needed to know in life, 
I learned from Dilbert* 


E veryone knows that objects and object-oriented 
(00) design are the hottest things since sliced bread 
(and, of course, slices of bread are objects). The prob¬ 
lem isthat it's hard to agree on what exactlythey are. There 
have been many attempts to define principles of 00 
design or coding, with varying degrees of success. In my 
opinion, most of them suffer from two flaws. First, they 
don’t tell me enough about how to code. Reading a defini¬ 
tion of "polymorphism" doesn’t tell 
me how to exploit it in my programs 
Second, and more important, isthat 
they’re dull. Even if the definition of 
polymorphism did tell me how to 
code, it’s hard to stay awake long 
enough to finish reading it. 

Therefore, I modestly present 
some of my own principles of 00- 
ness, which I hope address both of 
these flaws. Furthermore, I believe that these principles 
relate well to the corporate environments that have seen 
so much Smalltalk use recently 

NEVER DO ANY WORK THAT YOU CAN GET SOMEONE 
ELSE TO DO FOR YOU 

This is always good advice, but its particularly applicable 
in 00. In fact, I consider it the fundamental principle of 
00. As an object, my responsibilities are very clearly 
defined, and so are those of my co-workers. Ifsomething 
is (or ought to be) one of their responsibilities, then I 
shouldn't be trying to do that work myself. 

Let’s look at a concrete example: 

total : = 0 

aPlant billings do: [:each| 

(each status ==#paid and: [each date > startDate]) 
ifTrue: [total : = total +each amount]]. 

versus 

total: = aPlant totalBiIlingsPaidSince: startDate. 
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I n the fi rst case, we’re asking the plant for all of its billings, 
figuring out for ourselves which ones qualify, and com¬ 
puting the total. That’s a lot of work, and almost none of it 
is our job. Far better to use the second option, where we 
simply ask for something to be done and get a result back. 
In real-world terms, the first example is like the following 
conversation: 

"Excuse me, Smithers. I need to know the total bills 
that have been paid so far this quar¬ 
ter. No, don't trouble yourself. If 
you'll just lend me the key to your fil¬ 
ing cabinet I can go through all the 
records myself. I’m not familiar with 
your new filing system, but I'm sure I 
can figure it out. I’ll try not to make 
too much of a mess.” 

Smithers actually understands his 
fi ling system, so he can probably do the work faster than 
we can, and he’smuch lesslikelyto mess everything up. In 
attemptingto do hisjobfor him, we’rejust making things 
worse. Thi ngs wi 11 get worse when he switches over to that 
new filing system next week. We’d be far better off acting 
like a stereotypical tyrant boss. 

"SMITHERS! I need the total bills that have been paid 
since the beginning of thequarter. No, I'm not interest¬ 
ed i n the petty detai Is of your fi I i ng system. I want the 
total, and I'll expect it on my desk within the next half 
millisecond." 

Let’s look at a simpler example, which is all too common. 

somebody clients add: Client new. 
versus 

somebody addClient: Client new. 

There’s always a temptation to choose the first option, 
because it saves writing a couple of methods that do 
nothing but add and delete on the other class. But you 
know it’s wrong. You’re trying to do somebody’s work for 


* DilbertisatrademarkofUnited Feature Syndicate. 


I fyou must accept a 
responsibility, keep it 
as vague as possible. 
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them, and ultimately it's only going to cause problems Carried to the extreme, it seems this could lead tothesit- 

Writing those extra methods keeps the responsibility uation where everyone passes information around and 

where it belongs and will make the code cleaner in the nothing ever gets done. Exactly. Object bureaucracy at it's 

long run. finest. 

This principle is close to the more conventional idea Seriously, a good 00 system can actually approach this 
of "encapsulation", but I like to think it makes the idea state. Each object will do a seemingly insignificant 

somewhat clearer. I often see people who are happily amount of work but somehow they add up to something 

manipulating the internal state of another object, but much larger. You can trace through the system, seeking 

think it's OK because they’re doing it all through mes- the place where a certain calculation happens, only to 

sages. Encapsulation is not just realize that the calculation is fin- 

about accessing state, it's about ished and you just didn't notice it 

responsibilities. Responsibility is Never do dOyWOrk happening, 

about who gets stuck doing the real , 

work. tnatyoucan postpone decisions 


AVOID RESPONSIBILITY 

If responsibilities are about getting 
stuck with work, it's important to 
avoid them. This has some impor¬ 
tant corollaries: 


get someone else 
to do for you. 


• If you must accept a responsi bi I ity, keep it as vague as 

possible. 

• For any responsibility you accept, try to pass the real 

work off to somebody else. 

Our first principle tells us to take advantage of other 
objects when writing code. We also have to avoid being 
taken advantage of. Anytime I (as an object) am tempted 
to accept a responsibility, I should ask myself, "Isthis real¬ 
ly my job?" and "Can't I get someone else to do this?" 

If I do accept a responsibility, it's important to keep it 
as vague as possible. If I’m lucky, this vagueness will help 
me avoid doingthe work later. Even if I must do the work, 
it may allow me to take some shortcuts without anybody 
else noticing. 

For example, I’ve seen CRCswith responsibilities I ike: 

Maintain a collection of the who- 
sitsto beframified 

This is much too specific. My job isn't to maintain a 
collection, it's to beableto report, when necessary, which 
whosits need framification. That may be implemented by 
maintaining a collection, or by asking 
one or more other objects for their collection(s), it may 
be hard-coded, or computed dynamically as Whosit 
alii nstances select:. Regardless of which option I choose, 
there shouldn’t be any impact on my responsibilities. 

My preference for phrasing a responsibility of this 
kind is: 

Know which... 

but I'm flexible as long as the phrasing is suitably vague. 
I'd probably be even happier with 

"Beableto report which..." 


)neelse The great vi rtue of software \s flexibil¬ 

ity. One way we achieve flexibility is 
r yOU. through late binding. We most often 

discuss late binding between a 
method name and the method it 
invokes, but it’s also important in other contexts. When 
faced with a decision, we can gain flexibil¬ 
ity by postponing it. The remaining code just needs to be 
made flexible enough to deal with any of the possible 
outcomes. 

The ideal iswhen we can avoid makingthedecision at 
all, leaving it up to someone else (the end user, other 
objects). For example, consider the question of how to 
implement dictionaries. The standard thing to do is use 
a hash table. That works well for medium-sized collec¬ 
tions, but it's a waste of space and effort for very small 
collections. For very large collections, it may also be 
wasteful, particularly if the number of elements exceeds 
the resolution of our hash function. We must make a deci¬ 
sion here, so we’d I ike to postpone it or pass it off to some¬ 
one else. 

Some implementations of the collection classes do pre¬ 
cisely this. The col lections transfer much of their behavior 
to an implementation collection that actually does the 
work. Depending on the size, the nature of that collection 
can change. In VisualAge 2.0, small dictionaries were 
stored as arrays because the overhead of hashing was 
more than the cost of a linear search. Larger dictionaries 
could be represented as either normal or bucketed hash 
tables. This seems to have disappeared in 3.0, so I suppose 
the overhead of this mechanism became more than the 
cost of using a single representation. Visual Smalltalkalso 
has dictionaries that are capable of switching between 
normal and bucketed hash tables. 

Be careful in applying this principle because it's possi¬ 
ble to take it too far. Decisions aren’t just sources of prob¬ 
lems, they give us the power to solve problems. Because 
we cannot solve all the problems of the world at once, we 
make the decision to limit ourselves, and we make 
assumptions about the problems we’ll be given. The 
problem arises when our decisions were poor, or our 
assumptions don’t hold any more. The trick is to make 
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enough decisions to be able to work, but few enough that 
our code doesn’t become brittle. That’s one of the things 
that makes software difficult. 

Passing off decisionsto another object isoften referred 
to as using policy or strategy objects. This is discussed in 
Design Patterns 1 as the Strategy pattern. 

Other related ideas are "Open Implementations,” which 
can allow important decisionsto be postponed so far that 
even the end user of the module can control them. I can’t 
do justice to this topic here, but there’s a web page avail¬ 
able at http://www.xerox.com/PARC/spl/eca/oi.html 
Because web pages change so rapidly, I’ll also mention 
that I found it using the search terms open implementa¬ 
tion and Gregor Kiczaies (the project leader). 

POSTSCRIPT 

Although there is a significant element of humor in these 
principles, I do take them quite seriously and urge you to 
do the same. They i llustrate some very important aspects 
of 00 design and codi ng. I've even come up with enough 
ofthemtofill another column, so the next issue will con- 
tinuethistheme. ffi 
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person can cause damage more quickly on a Smalltalk 
project than they can on a traditional project, and corpo¬ 
rate cultural checks that normally help such people, such 
as peer reviews, management one-on-one meetings, and 
performance reviews, are tuned to the slower beat of the 
traditional project. 

Beginning a Smalltalk project offers the opportunity 
for a "behavioral context switch,” in which old patterns 
can be broken. By catching behavioral difficulties early, 
you can keep them from becoming established patterns. 
Once behavioral patterns are established, their impact 
on productivity must be carefully monitored and hu¬ 
manely dealt with. ffi 
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